Design of the PATHWORKS for ULTRIX File Server 



The PATHWORKS for ULTRIX product integrates personal computers with the ULTRIX operating 
system on a local area network. The software supports both the TCP/IP protocol and the DECnet 
transport stacks. The design and implementation of the PATHWORKS for ULTRIX file server is 
based on a client-server model. The server provides file, print, mail, and time services to client 
PCs on the network. Network file service management is accessed through a PC-style menu 
interface. The file server's performance was optimized to allow parallelism to occur when 
the client is generating data at the same time the server is writing the data to disk. 
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Introduction 

The PATHWORKS for U LTRIX file server connects 
industry-standard personal computers running Mi- 
crosoft's server message block (SM B) protocol to Dig- 
ital computers running the ULTRIX operating sys- 
tem. The server provides a network operating sys- 
tem for PC integration among users of theULTRIX, 
DOS, and OS/2 operating systems. 

The PATHWORKS for ULTRIX server provides 
file, print, mail, and time services to client PCs 
on the network. The software is layered on VAX 
systems and on reduced instruction set computer 
(RISC) hardware. It supports both the transmis- 
sion control protocol/internet protocol (TCP/IP) and 
the DECnet transport stacks. The base product also 
provides centralized server-based management ac- 
cessed through a PC-style menu interface. 

I n addition, the PATHWORKS for ULTRIX server 
implements a network basic I/O system (NetBIOS) 
naming service that allows clients on the network 
to obtain the DECnet node address of the server in 
the DECnet environment or the TCP/IP address of 
the server in the TCP/IP environment. The DEC- 
net NetBIOS naming service conforms to Digital's 
specification for a DECnet NetBIOS interface. The 
TCP/IP NetBIOS implementation conforms to the 
requests for comment, RFC 1001 and RFC 1002 
specifications.[l,2] 

This paper discusses the considerations for de- 
signing and implementing a PC local area network 
(LAN) server in an ULTRIX system environment. 
It describes the multiple process model and its com- 
ponent processes that coordinate management ac- 
tivities and server requests. It then presents our 



design of a management interface and our selec- 
tion of a network interface. Finally, the paper de- 
scribes the PATHWORKS file system, printing, per- 
formance considerations, and the server configura- 
tion. 



Process Model 

The process model selected for the PATHWORKS 
for ULTRIX server differed substantially from the 
process model chosen for the PATHWORKS for VM S 
product. The PATHWORKS for VMS server uses 
a single process model in which all client requests 
are processed by a single process, the VMS server. 
The PATHWORKS for ULTRIX server, in contrast, 
uses a multiple process model, in which one client 
is serviced by one server process. 

Certain characteristics of the ULTRIX operating 
system environment determined the choice of a mul- 
tiple server process model. First, the ULTRIX op- 
erating system constrains a process to 64 simulta- 
neously open files. Therefore, with multiple server 
processes, each client connection is allowed access 
to 64 open files. In a single process model, a pod 
of 64 file descriptors is provided which limits access 
to 64 open files, regardless of how many clients con- 
nect. I n addition, the multiple server process model 
has the advantage of being able to run in a multi- 
processor environment. 

Within the context of the multiple process model, 
werequired a central administrative entity— the ad- 
ministration process— that would coordinate man- 
agement activities and server requests. The ad- 
ministration process communicates with server and 
management processes through message queues. 
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This process model is depicted in Figure 1 and is 
described in the following sections. 
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Figure 1 PA TH WORKS for UL TP, IX Process 

Administration Process 

The administration process is known as pcsaadmd. 
As the central administrative entity, this process 
is responsible for initialization and start-up of the 
server, and for data management while the server 
is running. Starting the PATHWORKS for U LTRIX 
server is accomplished through execution of the ad- 
ministration process from within the rclocal file 
when the ULTRIX system is booted, or from the 
management menu when the management interface 
is run. Initialization of the server environment is 
necessary before any server management or connec- 
tions can be established. 

Initialization involves starting the NetBIOS pro- 
cess (pcsanbud), parsing the configuration file (Ian- 
man. ini), creating and initializing a shared mem- 
ory segment, creating semaphores and a mes- 
sage queue, parsing the services database, clearing 
statistics, defining objects on the DECnet objects, 
and establishing signals. The main task of the ad- 
ministration process is processing requests from the 
management interface (pcsamgr) and file server pro- 
cesses (pcsafs). The initialization procedure occurs 
in the following sequence. 

To simplify server start-up, theNetBI OS process is 
started from the administration process. At start- 
up, the NetBIOS process claims the server name 
and responds to name queries from clients during 
establishment of a session connection. It also pro- 
vides for sending datagram and broadcast messages 



on the LAN. These two tasks are initiated by the 
user through the management interface by means 
of the Send and Broadcast Message functions. All 
management requests are processed through the ad- 
ministration process. Request handling is discussed 
in more detail later in this section. 

The administration process parses the lanman.ini 
file to obtain server configuration parameters such 
as maximum number of sessions, connections, and 
open files. The administration process uses these 
parameters to establish the size of the shared mem- 
ory segment it creates. The shared memory segment 
includes a session database, a connection database, 
a file database, common variables, and a locking 
database. Once shared memory is created, the ad- 
ministration process initializes it to a known state 
that includes clearing and date stamping the server 
statistics portion of the segment. The administra- 
tion process creates semaphores to attain data in- 
tegrity in the shared memory segment, since multi- 
ple file server processes read and write to memory. 

The services database tracks file and print service 
creation from one execution of the server to another. 
This database is read at initialization, and the di- 
rectories offered by the file service defined, as well 
as printer information, are verified. 

The last step required at initialization is the cre- 
ation of a message queue to process incoming re- 
quests from the management interface and file 
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server processes. As previously stated, request pro- 
cessing is the main task of the administration pro- 
cess. Message queues are used as the interprocess 
communication mechanism. Early in the process de- 
velopment, we investigated other options: named 
pipes, sockets, and packet passing through shared 
memory. Only message queues offered administra- 
tive control. Initially, weused one response message 
queue for each file server process and one queue for 
the management interface. This was unacceptable 
because the default number of message queues on 
the U LTRIX system is 40 without reconfiguring the 
kernel. Therefore, we chose to combine the mes- 
sages on one response queue from all the file server 
processes and retain a separate response queue for 
the management interface. Since the number of 
requests from file server processes is small, this 
method was acceptable. The administration process 
reads requests on one message queue and repl ies to 
a message queue defined in the message. The re- 
quest queue is established with an I D known by all 
processes so they can attach to the queue at start- 
up. The administration process handles requests 
for session establishment and connection from file 
server processes as well as requests for system man- 
agement/administration from the management in- 
terface. 

File Server Process 

The PAT H WO R K S for U LT R I X fi I e server i s started 
through one of two mechanisms, depending on 
which transport is used. The dnet_spawner process 
starts the file server process in a DECnet environ- 
ment, and the inet_spawner starts the server in a 
TCP/IP environment. The server process is initially 
started as a root process, since it may need to run on 
behalf of several users. When a client issues a con- 
nection request, a server process is initiated. The 
server then sends a message to the administration 
process message queue requesting a session connec- 
tion. After the session connection is granted by the 
administration process, the file server completes its 
initialization by connecting to shared memory and 
waiting for incoming client requests. 

During the design phase of the multiple server pro- 
cess model, it became clear that using a slow in- 
terprocess communication mechanism has a detri- 
mental impact on the overall performance of the 
server. For this reason, we decided to use shared 
memory for all time-critical shared data. Because 
the amount of shared memory is somewhat limited, 
all data that is not time critical is communicated 
across message queues. As can be seen in Figure 
1, the file server and administration processes use 
shared memory as well as message queues for com- 
munication. 



Since multiple processes can simultaneously up- 
date and access shared memory, a method was 
needed to guarantee data integrity. The methods 
chosen varied among the databases, depending on 
the type and speed of the access required to the 
database. Obviously, the easiest and also the slow- 
est way was single-process management of access to 
shared memory. This worked well in the case of allo- 
cating connection data blocks, since the administra- 
tion process had to be notified of connections. The 
open and read-write paths for the file and locking 
database, however, would be significantly affected 
by an incorrect decision. For this reason, we de- 
cided to protect these databases with an ULTRIX 
semaphore. In effect we single threaded all the 
paths through the open path as well as the locking 
update path. Use of this semaphore caused little 
or no degradation in performance. With our system 
processes and mechanisms established, we now had 
to consider the needs of the system administrator. 



Management I nterface 

Our primary goal in designing a management in- 
terface for the PATHWORKS for ULTRIX server 
was to provide an application that could run un- 
altered on any type of terminal. The management 
interface also had to be consistent in presentation 
and manipulation of screens; and most importantly, 
it had to be easy to use when managing file and print 
services, workstation registration, and U LTRIX sys- 
tem users and groups. Other design considerations 
included performance, the ability to extend the func- 
tionality provided, and the ability to port the appli- 
cation to future platforms. 

The management interface was designed to incor- 
porate X/Open Curses software, which is a set of 
C library routines. X/Open Curses is provided by 
the ULTRIX operating system and is used to opti- 
mize screen management. X/Open Curses code uses 
the terminfo database, a collection of terminal def- 
initions and characteristics that enables the appli- 
cation writer to perform terminal -dependent func- 
tions in a terminal -independent manner. Through 
X/Open Curses software and its use of the terminfo 
database, the PATHWORKS for ULTRIX manage- 
ment interface can support any type of terminal. [3] 

The next step was to design an easy-to-use ap- 
plication that requires minimal knowledge of UL- 
TRIX system management. We selected a PC- 
style format that uses pull-down menus, input 
forms, scroll regions for displaying information, and 
screen-sensitive help. Default input information is 
displayed whenever possibleto provide sample data 
and to minimize the amount of input required. 
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The design of the management interface was struc- 
tured into three layers: screen manipulation, data 
validation and presentation, and application pro- 
gramming interface (API). 

Screen Manipulation 

The first layer of the management interface is the 
X/Open Curses software. All screen manipulation 
routines reside at this level. X/Open Curses en- 
compasses the implementation of reverse video at- 
tributes for highlighted text, cursor movement, win- 
dow updates, and the creation of menus, forms, and 
scrolling regions. Any type of screen interaction is 
performed and managed by this layer of code. As 
a result, the screen manipulation layer is portable 
to any environment in which X/Open Curses is sup- 
ported. 

Data Validation and Presentation 

At the data validation and presentation layer, data 
obtained from the screen interface is validated. The 
data is then packaged and processed by the API 
layer. Information returned by the API layer is un- 
packed and formatted for screen presentation. 

Application Programming Interface 

The API layer is responsible for all communication 
with the administration process. The management 
interface does not store or manipulate server man- 
agement data directly. Instead it makes requests 
of the administration process in the form of APIs 
through message queues. Each request requires a 
response and does not complete until a response is 
received. 



Network Interface 

When designing an application that must commu- 
nicate on a network, one of the important decisions 
is how to control access to the network. The Berke- 
ley Software Development version 4.3 of the UNIX 
kernel, upon which the ULTRIX operating system 
is based, provides two network interfaces. 

The first network interface is known as the socket 
interface. It uses a socket structure to identify the 
endpoint of an ULTRIX network connection. Un- 
der the ULTRIX system, the socket interface is the 
primary interface to the network. 

The second network interface in the ULTRIX sys- 
tem is the X/Open transport interface (XTI). This 
transport service interface is not restricted to either 
the DECnet or theTCP/l P transport. A common in- 
terface to the network allows either transport to be 
accessed transparently. With XTI the communica- 
tion endpoint is identified by a local file descriptor. 



On the ULTRIX system, the XTI interface is pro- 
vided through a library that converts the XTI calls 
into socket calls. Since performance was one of our 
primary concerns, we decided to use the socket in- 
terface because it connects directly to the ULTRIX 
operati ng system. 

MultipleTransport Support 

I n order to support both theTCP/l P and the DEC- 
net transports, we needed to overcome the dif- 
ferences between a message-based protocol (DEC- 
net) and a stream-based protocol (TCP/IP). With a 
message-based protocol, data received from the net- 
work arrives in compact packets. With a stream- 
based protocol, message boundaries are not pre- 
served; the data flows in a stream. Since Mi- 
crosoft's SMB protocol is a message-based protocol, 
the server needs to re-create these message bound- 
aries. As a result, the server must identify the 
transport provider. This information is provided by 
the socket layer when the server process is started. 
The server can re-create the message boundaries by 
combining this information with message size in- 
formation provided in the TCP/IP NetBIOS header. 
With the message boundary information, the server 
can re-create the message. The C pseudocode frag- 
ment in Figure 2 shows the instructions to re-create 
message boundaries. 

PATHWORKS File System 

The PATHWORKS file system provides an appli- 
cation layer that attempts to emulate the DOS file 
system. Several trade-offs and restrictions were re- 
quired in order to implement this file system on the 
ULTRIX file system. This section describes these 
trade-offs and restrictions and explains our design 
choices. 
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/* SMBptr - Pointer to SMB netbios header */ 

/* rdlen - Number bytes read from network */ 

/* BytesRcvd - Bytes already received */ 

/* BytesLeft - Bytes left in current message */ 



rdlen-read (network, SMBptr) ; 
BytesRcvd-rdlen; 

BytesLeft^sizeof (netbios header) ; 

BytesLeft+=ntohs (EXT16 ( SMBptr->nb . length) -bytes_rcvd; 

/* We will wait until we receive all the data in the msg */ 
/* before we terminate this loop. This loop will only be */ 
/* entered if we are running TCP/IP. */ 

while (BytesLeft != 0) { 

rdlen-read (network, &SMBptr [BytesRcvd] ) ; 

/* If we don't get any data it means the client must have */ 
/* torn down the session so abort */ 

/* our session. Note AbortSession ( ) must exit and*/ 
/* not return here.*/ 

if (rdlen<=0) AbortSession () ; 

/* Update the counters to account for what we just read */ 

BytesRcvdt-rdlen ; 
BytesLef t --rdlen; 

} 

/* If this is a SESSION_REQUEST message, then send the ACK*/ 
if (SMBptr->nb.type == SESSION_REQUEST) SendSessionAck ( ) ; 
/* If this is a SESSION_MESSAGE, then handle the SMB */ 
if (SMBptr->nb.type == SESSION_MESSAGE) DispatchSMB ( ) ; 



Figure 2 Receiving Stream Data Code Fragment 



File Name Mapping 

The file name space in the U LTRIX system is not 
restricted to the 8.3 naming format supported by 
DOS. DOS limits file names to eight characters fol- 
lowed by an optional period and an optional three- 
character extension. This is referred to as DOS 8.3 
file name format. DOS file names are uppercase 
characters and are case insensitive. U nder the U L- 
TRIX system, the file name is a 32-character string 
in which the period (.) is a legal character. The 
ULTRIX file system is case sensitive and supports 
both uppercase and lowercase characters in the file 
name. 

To resolve this incompatibility between operating 
systems, we mapped the DOS file name space into 
the U LTRIX file name space. DOS, bei ng case i nsen- 
sitive, views the world of file names in uppercase, 
but U LTRIX file names are typically lowercase char- 
acters. We chose to map all DOS file names to the 
equivalent lowercase name. Any file on the host 
ULTRIX operating system that meets our criteria, 
i.e., lowercase names and 8.3 format is visibletothe 
DOS client. 



This approach was suitable in all environments 
except International Standards Organization (ISO) 
9660 CD-ROM file systems. These file names con- 
form to the DOS uppercase, 8.3 file naming format. 
When the file server determines that one of the ser- 
vices is on an ISO 9660 CD-ROM file system, the 
file-name mapping algorithm is changed to allow 
only uppercase file names that follow the DOS 8.3 
format. 

DOS Attribute Mapping 

The DOS file system provides file attributes that 
do not necessarily map to ULTRIX file attributes. 
The challenge was to preserve these DOS attributes 
within the ULTRIX file system without impacting 
the host system user who might also be sharing the 
file. The DOS attributes consist of read-only, hid- 
den, archive, and system. 

The DOS read-only attribute maps directly to the 
ULTRIX directory attributes mask. If the write at- 
tribute is turned off under the U LTRIX system, the 
files change to read-only status. 

The DOS hidden attribute specifies that a file 
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should not bedisplayed on a normal directory search 
/lookup. We mapped this bit to the U LTRIX set user 
ID bit. 

The DOS archive attribute specifies that a file has 
been changed since the last time the archive at- 
tribute was set. It is generally used by the backup 
program to determine which files have changed 
since the last backup. We mapped the archive at- 
tribute to the ULTRIX set group ID bit. 

The DOS system attribute specifies a special sys- 
tem file that is normally not displayed on a direc- 
tory listing, and in some cases is not backed up. We 
mapped the DOS system attri bute to the Owner ex- 
ecute bit. If this bit is set, the server cannot include 
these files on a normal directory search, unless re- 
quested. 

Byte Range Locking 

The most noticeable difference in byte range lock- 
ing between the U LTRIX operating system and the 
DOS operating system is that byte ranges under 
the ULTRIX system are purely advisory. Advisory 
locking works as a mechanism to signal that a byte 
range is currently in use. TheULTRIX system, how- 
ever, does not enforce the locks; therefore it is possi- 
ble to read/write a byte range that is locked simply 
by ignoring the lock. 

On the other hand, DOS has mandatory locking. 
If a byte range is locked, the user can neither read 
nor write a locked byte range. We needed to convert 
the ULTRIX lock manager into a mandatory lock 
manager from the DOS clients' point of view. To do 
this, the ULTRIX lock manager has to check for a 
lock on a byte range on every read or write from the 
file server. If any portion of the byte range is locked, 
the client receives a lock failure message. 

I n the initial release of the server, we believed that 
the standard ULTRIX lock manager would provide 
enough performance and granularity to allow DOS 
client software to function correctly and quickly. We 
learned that this was not always the case. For ex- 
ample, in a network file system (NFS) environment, 
additional time for granting or denying the lock re- 
quest was needed to resolve a lock on the network. 
In addition, the ULTRIX lock manager viewed the 
byte range as a signed integer, but the DOS lock 
manager viewed the byte range to be locked as 
an unsigned integer. This disparity led to prob- 
lems with applications that used byte range locks 
with the sign bit set to provide synchronization for 
database updates. We found that the U LTRIX lock 
manager was deficient in the DOS client environ- 
ments. For these reasons, we decided to write a 
private lock manager for applications that could not 
use the ULTRIX lock manager. 



To resolve locking problems among these applica- 
tions, we designed a private lock manager for the 
PATHWORKS for ULTRIX server. We provided a 
high-performance lock manager that could lock byte 
ranges used by DOS applications. In other words, 
the server lock manager would treat the lock range 
as an unsigned number instead of a signed num- 
ber. We also provided the option of passing the lock 
information to the ULTRIX lock manager for those 
applications that needed this functionality. 

Open File Mode Locking 

The DOS client provides a mechanism for control- 
ling access to opened files. It allows the client who 
initially opens a file to control access to the file 
by other clients. The DOS client allows files to be 
opened in one of four modes: 

• DENY_NONE mode allows all types of files to be 
opened by al I users. 

• DENY_READ mode allows other users to open 
the file for writing but not reading. 

• DENY_WRITE mode allows other users to open 
the file for reading but not writing. 

• DENY_READ_WRITE mode does not allow other 
users to open the file. 

The ULTRIX operating system, on the other hand, 
has only two modes for a shareable file lock. The 
first is SHARE D_ACC ESS mode, which allows mul- 
tiple readers and writers and is therefore equivalent 
to the DENY_NONE mode. The other is EXCLU- 
Sl VE_ACCESS mode, which does not allow multiple 
accesses to the same file and therefore is equivalent 
to DENY_READ_WRITE mode under DOS. 

Because of these differences, we attempted to 
map the two modes not covered by the ULTRIX 
file lock manager, the DENY_READ and DENY_ 
WRITE modes. After some investigation, we de- 
cided mapping was not necessary. If a file was 
opened in one of these two modes, we specified that 
the ULTRIX server should open the file in ULTRIX 
SHARE D_ACCESS mode. We reasoned that an U L- 
TRIX application that was cooperating with a DOS 
application would not use these two modes to open 
the file since they are not available under the UL- 
TRIX system. Obviously these two modes need to 
be supported among DOS-based PCs on the server. 
Each time a user opens a file, the list of currently 
opened fi I es i s scanned to enforce the open mode and 
to be sure that the ULTRIX operating system con- 
forms to the DOS interpretations of these modes. 
Therefore, only the half deny modes being passed 
through to the operating system are not enforced. 
This design decision should pose no danger to appli- 
cations sharing data. 
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Directory Search Implementation 

The DOS file search algorithm and the SM B mes- 
sages that provide support for directory searches 
were difficult to implement on the ULTRIX file 
server. The core SMB protocol provides only two 
states for a search context, begin new search and 
continue a previous search. However, the server 
needs to be informed that the client has completed 
a directory search context. Then the server would 
be able to free local data associated with the search 
context. The implementation of this SM B posed two 
challenges: howtocontrol the amount of memory re- 
quired and how to map a search continuation iden- 
tifier. 

To minimize the amount of memory required to 
maintain search contexts, we designed a table of 
search context structures that contains a local tim- 
ing value. If the table becomes full and a block 
(structure and time value) needs to be reused, the 
oldest block is deemed reusable. This approach effi- 
ciently manages the unpredictable memory require- 
ments of an SM B search. 

The search continuation provides a directory in- 
formation structure which contains a four-byte field 
that determines the point at which the search is to 
continue. This four-byte field is well suited to the 
ULTRIX file system. The gnode field, a longword, 
can be used for the four-byte field's search continu- 
ation ID. Given this ID, the server has the ability 
to parse the contents of the directory until it finds 
a file with a matching gnode; it then continues the 
search from that point. 



PATHWORKS for ULTRIX Printing 

In addition to file services for DOS and OS/2 
system-based clients, PATHWORKS for ULTRIX 
provides print services for these PC clients. Our 
design objective was to allow the PC clients access 
to all the functionality on the native U LTRIX print 
queue in a transparent manner. A second objective 
was to implement the functionality provided by NET 
PRINT, the client utility for printing, on the native 
ULTRIX line printer daemon (LPD). 

Although the LPD provided all the basic printing 
capabilities, it did not provide timed scheduling of 
print jobs. To enable timed scheduling, we added 
the /AFTER switch to the server through a mecha- 
nism within the ULTRIX operating system. When 
a /AFTE R switch is detected in one of the extended 
printing SMBs, a batch job is run at the time spec- 
ified in the print request. 

The ULTRIX print spooler provides spooling for all 
types of printers, e.g., those attached locally as well 



as network printers and reverse Local Area Trans- 
port (LAT) printers connected to PCs. Reverse LAT 
printing is very important in our environment be- 
cause most PCs have printers attached and most 
installations have a need to share those printers 
among several PCs. 

The ULTRIX print spooler provides print filters 
which translate files to various printers. Print fil- 
ters conceptually sit between the LPD and the ac- 
tual file to be printed. During printing, the LPD 
reads a "printcap" file to determine if a print fil- 
ter is associated with this queue. The print filter 
is started in a forked process with its standard out- 
put device (stdout) pointing to the printer and its 
standard input device (stdin) pointing to the input 
file stream. The print filter is responsible for con- 
verting the file from the input stream (stdin) into a 
device-specific output that is usable by the printer 
(stdout). This feature allows the PATHWORKS for 
ULTRIX server to support printing on a wide vari- 
ety of third-party printers. 

The design of theULTRIX printing subsystem en- 
abled the PATHWORKS for ULTRIX server to pro- 
vide an interface to many different printers and 
printer configurations easily and efficiently. 



Performance Considerations 

As part of the design process, we observed the per- 
formance of the file server during interactions with 
the cl i ent . We needed to compare var i ous confl icting 
alternatives and their effects on the overall perfor- 
mance of the server. Some of the alternatives we 
studied were the advantages of using the ULTRIX 
system cache versus implementing our own cache. 
We also studied the issue of persistent lock requests 
on the network and the server. These alternatives 
are discussed in this section. 

File 1/ 0 

Since the ULTRIX operating system provides a 
kernel-based, disk cache mechanism, we designed 
the operating system's cache manager to perform 
all caching globally. The cache manager updates the 
cache buffers, performs read ahead on data streams, 
and flushes the cache buffers from data written to 
disk. 

The file server performs disk writes as write be- 
hinds. When a request to write data is received 
from a client, the server responds by acknowledging 
success before the write is attempted (assuming the 
client has proper write access to the file). This op- 
timization allows parallelism to occur between the 
client and the server because the client is generating 
more data at the same ti me the server is wri ti ng the 
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data to disk. If the write fails, however, the server 
notes that the last write failed and returns the error 
on any subsequent access to the file. 

Heuristics 

We found that certain applications would continu- 
ally flood the server with lock requests even though 
the lock requests kept failing. These persistent lock 
requests from applications used valuable CPU time 
on the server system as well as network bandwidth. 
For this reason, the U LTRIX server needs to deter- 
mine if a client is being persistent and continually 
requesting locks which are failing. When the server 
detects continuous lock requests, it delays the lock 
request for a random period of time and then checks 
if the lock has become available. The server then ei- 
ther grants access if the lock is available, or returns 
the error at that time. This procedure reduces lock 
request traffic, since most locks are of short dura- 
tion. 



Security 

Connection requests between client and server re- 
quire a security check. Since PATHWORKS for UL- 
TRIX was designed to be layered on the ULTRIX op- 
erating system, we were able to take advantage of 
its security features. When a client attempts to con- 
nect to the server, a username and password can be 
passed as part of the connect message. If these are 
supplied, the user is validated through system calls 
to obtain the password file entry for that user. If 
the user is not found in the /etc/passwd file or if the 
password is invalid, the user is denied connection. 
If the ULTRIX system is running in enhanced se- 
curity mode, further checks are made to ensure the 
account has not been disabled or the password ex- 
pired. In either of these cases, the connection would 
be denied. If a username is not supplied, a default 
guest account may be used to establish privileges. 

VAX Versus RISC Considerations 

During the development of the PATHWORKS for 
ULTRIX file server, we did not anticipate that our 
code would have to differentiate between VAX and 
RISC architectures. We expected that code writ- 
ten for an ULTRIX system in a RISC environment 
would be recompiled on a VAX system. For the most 
part, our assumptions were correct, except in the 
areas of memory allocation. On the VAX system, 
shared memory maps directly after the data seg- 
ment in memory. This implementation prohibits the 
allocation of memory above a shared memory seg- 
ment. In the RISC implementation, shared mem- 
ory is allocated at the very top of the memory i mage; 
therefore a great deal more memory can be al located 



before the bottom of the shared memory segment is 
reached. The difference in shared memory alloca- 
tion between the RISC and VAX systems is shown 
in Figure 3. 
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Figure 3 Image Memory Layout 



To increase the data segment size in the VAX 
system, we replaced all malloc()with the following 
pseudocode: 

Disconnect from shared memory mallocO 
Reconnect to shared memory 

Since this code is required only in a VAX environ- 
ment, it is compiled when the server is built. 



PATHWORKS Server Configuraion 

The PATHWORKS for ULTRIX file server allows 
the system manager to configure the server envi- 
ronment to make the most efficient use of shared 
memory. The following parameters included in the 
lanman.ini file are the determining factors that en- 
able shared memory to be scaled. 

• maxsessions: The maximum number of PC work- 
stations that can be simultaneously connected to 
the PATHWORKS for ULTRIX server. 

• maxconnections: The maximum number of con- 
nections PC workstations can make to the ser- 
vices offered. 

• maxopens: The maximum number of files the 
server can have open simultaneously. 

• uniqueopenfiles: The maximum number of unique 
open files the server can have open simultane- 
ously. 

• maxserver locks: The maximum number of byte 
range locks the server can lock simultaneously. 
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To help the user apply these parameters to a par- 
ticular system, the "pcsa memory" command acts as 
a shared memory sizing calculator. It allows the 
user to input the parameters and then either indi- 
cates that the new parameters will fit in the current 
system, or that the system shared memory param- 
eters need to be changed to support the new config- 
uration. 



Information Logging 

PATHWORKS for ULTRIX information logging 
was designed for the ULTRIX system manager as 
well as writer/users of the LAN Manager applica- 
tion. It provides event and error logging informa- 
tion in two distinct formats. The first format uses 
the U LTRIX system log file: syslog. This log file is 
typically monitored by ULTRIX system managers. 
All processes which comprise PATHWORKS for UL- 
TRIX submit configuration information and error 
conditions to this file. The file server process also 
logs information regarding service usage, sessions, 
and connections. 

The second form of event logging is performed 
entirely by the server process. The server pro- 
cess logs error and audit events to LAN Manager- 
compatible log files: error log and audit log. These 
log files are accessible through the management in- 
terface as well as through the LAN Manager API 
interface provided with DOS and OS/2 LAN Man- 
ager implementations. These files contain informa- 
tion on session logon/logoff, password errors, con- 
nections started/rejected, resource access granted 
/denied, and server status changes. 



Summary 

The PATHWORKS for ULTRIX file server, to- 
gether with the PATHWORKS for DOS and PATH- 
WORKS for OS/2 products, provides a distributed 
computing environment. The file server is based on 
a client-server model that offers transparent access 
to ULTRIX system resources from PC clients. It 
provides the necessary tools to integrate these two 
diverse computing environments in a manner that 
is both efficient and easy to manage. 
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